xen: arm64: Handle memory banks which are not 1GB aligned

xen: arm64: Handle memory banks which are not 1GB aligned

The code in the arm64 version of setup_xenheap_mappings was making
some very confused attempts to handle this but was bogus.

As well as adjusting the mapping to start on a 1GB boundary we also
need to account for the offset between the start of the mapping and
the actual start of the heap when converting between page pointers,
virtual addresses and machine addresses.

I preferred to do this by explicitly accounting for the offset rather
than adding an offset to the frametable because that approach could
potentially waste a large amount of frametable (up to just less than
1GB worth) but also because of issues with converting mfns from
outside the regions considered for pdx initialisation (which are not
1GB aligned) back and forth.

We already have an idea of the distinction between the start of the
direct map and the start of the xenheap in the difference between
DIRECTMAP_VIRT_START and XENHEAP_VIRT_START. Until now these were the
same thing, but now we change XENHEAP_VIRT_START to point to the
actual start of heap not the mapping. Surprisingly there was only one
place which was using the conceptually wrong value.

Also change xenheap_virt_end to a vaddr_t for consistency.

We've been lucky so far that most hardware happens to locate memory
on a 1GB boundary (we did have reports of a system with memory at a
half gig boundary which exhibited failures which I didn't manage to
follow up on successfully). The EFI support has exposed this
shortcoming by the way it handles reserved memory, which has a
similar effect to having memory non-1GB aligned.

arm32 does things differently here due to using a small Xen heap and
a demand mapped domain heap, so isn't affected.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Suravee Suthikulanit <suravee.suthikulpanit@amd.com>
Cc: Roy Franz <roy.franz@linaro.org>
Cc: Vijay Kilari <vijay.kilari@gmail.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
Tested-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Roy Franz <roy.franz@linaro.org>